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IDENTIFIERS 
ABSTRACT 

It is recognized that there is a najor gap between 
th^ promises of large data bases and eptinization and simulation 
models and their actual ability to solve real world problems. This 
ds^ttitnt describes a Generalized Data Base Planning System (GPLAN) » 
Cttff#ntly being developed at Purdue Oniversityj that is proposed as a 
syst^i to bridge this gap. A number of systems contain some of th# 
€olf,aindnts of GPLAN, and a survey of each system is presented with 
details of its contribution to GPLAN dessign. Research on two systems 
at fQtdtte is directly leading to the development of GPLAN. One 
apflication is concernei with the development of a regional water 
poiiiition control planning system; the other is an interactive 
Infotiation system design paekage* The attthors suggest that GPLAN Is 
as ioih a major advance over a Generalized Data Management System 
(GS8§) as a GDHS is a major advance over applioation programs with 
formatted sequential files. A bibliography is included. Diagrams may 
reptoduoe poorly* (Author/DN) 
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ABSTRACT 



It Is recognized that there Is a major void between the promises of 
large data bases and optimization and simulation models and their actual 
use to solve real world problems. A Generalized Data Base Planning 
System (GPLAN), currently being developed at Purdue University, is pro- 
posed as a system to birldge this gap. A number of systems contain some 
of the components of 6PLAN, and a survey of each system is presented with 
details of its contribution to GPLAN design. 

Research on two systems at Purdue University is directly leading to the 
^ development of GPLAN. One application is concerned with the development 
of a regional water pollution control planning system^ and the othet 
application is an interactive information system design package. 

A Generalized Data Base Planning System is not Just a new name 
for A Generalized Data Management System (GDMS), but represents a new 
generation of software^ GPLAN is as much a major advance over a GDMS^ 
as a GDMS is a major advance over application programs with formatted 
sequential files. 
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G PLAN: A Generalized Data Base Planning System 
J. F. Nunamaker, Jr., D. E. Swenson, and A. B. Whinston 

Purdue University 

Introduction 

Societal problems and industrial problems, if they are to be studied 
analytically, will require two broad components: first, a structure or model 
to analyse the interaction of the variables; and second, a large scale data base* 
The data base may be used in various ways, such as validation of the model's 
paraineters, input data for actual runs of the model, and simply providing the 
data itself for other interests. While the ability to devise meaningful models 

H with appropriate supporting data is of primary importance for the advancement of our 

capacity to serve societal and industrial needs, the possibility of integrating the 
data base handling techniques with techniques of simulation and optimization will 
greatly facilitate this work. 

With the advent of large scale computers and complex operating systems 
during the last six years, the capacity exists for the processing of large seal© 
applications. In addition, much work has been done with respect to the developffient 
of Generalized Data Management Systems (dDMS)*which were designed to handle- and 
manage large data bases. Typically, such systems have been used by managemefit 
of large industrial and military organizations. These systems are used for 
handling inventory, receivables, customer accounti!ig and billing, quality 

^ control and oth^r administrative tasks. 

Generalized Data Management Systems have contributed to inereased use e£ 

i 

eemputers, but a major void still exists. The problem of many applieation pr©gfaffis 
interacting automatically with a single data base remains a major barrier to 
general use of an information system as a planning system, 
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The use of an information system as a planning system will come about only 
when a methodology exists for automatically creating the data files needed by the 
many application programs and answering general queries of the data base at the 
same time. What is needed is a software system that, as a* result of a specific 
query from a user, can: 1. retrieve the data necessary to answer the query; 
and/or 2. set up the application program or model that must be run to answer 
the query. This requires that the data be automatically retrieved and arranged 
in the proper format required by the model. 

The value of such a software system is based upon; !• the efficiency of 
storing and retrieving data; and 2» the range of services provided through the 
interactive query system. 

The planning system must be designed so that the user is freed from the 
mundane task of data preparation, which can be tedious and frought with human 
errors, in order to lun a model. Often, the user is not familiar with the problems 
and procedures of data handling, and, in most cases, would, prefer not being 
bothered with the data handling at all, 

A user who has juSt queried a data base will have gained very little if 
he must further select, re-arrange, reformat, and punch his retrieved data 
for input to an application program or model. Thus what is needed is a General izi&d 
Data Base Planning System (GPLAN), which results from the extension of a Generalized 
Data Management System to handle the automatic setup^ of models from a Data Base 
as instructed by the user through the Query Language, GPLAN is a natural extension 
of GDMS and represents the next generation of GDM3*s. 

In many areas, there has been considerable work on development of simulatioft 
and optimization packages, with the end result that these packages are not fdaliy 
used by the people who should be using them. The reasons for this huge investment 
in application packages with little resultant usefulness ajfe simple. The paekages 
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are so difficult to use, requiring either veiy much technical knowledge in the ' 
particular mathematical programming technique and/or complex file setup and manipulation 
steps, that few people are able to use the package without relying heavily on 
technical help or considerable education in the specifics of each particular 
package. 

It is obvious that to increase the usefulness of simulation and optimization 
packages, the nontechnical and/or management personnel who are knowledgeable in 
the general area of endeavor should be able to easily use these packages. 

What is proposed here is to generalize data base planning systems. For a 
specific area of human endeavor needing such a system, this would mean that it 
would be easy to set up a data base, link it with application packages, and query 
it in a meaningful manner in short, it would be easy to set up a generalized 
planning system. This would mean that ad hoc solutions to specific areas 
would be replaced with a generalized approach comprehensive enough to solve 
many of the problems occurring in setting up specific planning systems. 

In order to take advantage of the knowledge that can be gained from the 
consideration of specific systems, a regional water pollution control planning 
system is described briefly and used for some examples throughout the rest 

of the paper. This system is discussed in order to develop the proper motivation 
for a Generalized Planning System, 
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Water Pollution Control Planning System 

The purpose of the water pollution control planning system is to develop 
a plan that minimizes the cost of pollution abatement structures while 
satisfying a set of water quality goals throughout an entire river basin. 
This planning system uses the most prevalent measure of water quality in 
use today, the level of dissolved oxygen concentration. 

The constraints of this model are constructed by dividing the river into 
sections and constraining the water quality, interpreted as the dissolved 
oxygen deficit level, to be met at the end of each section. Starting from 
the headwaters of the river, new sections are defined whenever the river 
parameters change significantly, such as effluent flow entering the river, 
incremental flow entering the river (tributary flow, ground water, etc.)> 
the flow in the main channel being augmented or diverted, or the parameters 
describing the river changing gradually over a longer distance. 

The quality constraints are sequentially dependent lii that the quality 
in each section is a function of the quality in the preceding section. 
But the possibility of tributaries, flow augmentation, and incremental and 
effluent flows entering at downstream points, complicates the relationship 
between the constraints. | 

Three possible treatment techniques are allowed for in the model: 
1. by-pass piping; 2. regional and on-site treatment plants; and 3. flow 
augmentation. Thus piping flows arc allowed from each polluter to each 
river section, from each polluter to each treatment plant, and from 
each treatment plant to each river section. 

In addition to quality constraints, flow conservation constraints are 
needed for both the polluters and the treat.Tient plants. 

The solution technique of the model Is the use of a general purpose 
non-linear algorithm adapted for this model. The major problem involved 
in adapting the algorithm was the calculation of the partial derivatives 
of both the constraints and the objective function. These paftlals were ^ 
necessary to set up a local Linear Progratratilng problem to detetftttlne the 
direction of search In the stepwise tionllnear problem. Starting with & 
point In the domain of the objective function, a new point le CdlcuUted it&m 
it by making a step to either reduce the velue of the objeetlve futictlofli 
If the original point is a feasible solution to the nonlinear progratRffilng 
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pi^oblem, or obtain a ''more feasible" solution if the point is en 
iufeasible solution ("more feasible" by reducing the value of the 
most infeasible constraint). 

The cost function essnntiaily involves the costs of new or upgraded 
treatment plants, reservoirs for flow augmentation, and various costs of 
new pipes to or from the polluters, treatment plants, and river f^ectionu. 

Di fficult:y with the Present Approach 

let us take an example of solving a mathematiccil prograrimlng problem 
(although any complex application problem would be similar), bucb as the 
nonlinear progranunlng model discussed in the water pollution control planning 
system. A programmer with knowledge of mathematical programming theory, or 
a group of people which together has the required knowledge, would write and 
check out a program to solvc: the specific problem. ''>1ien data would be 
gathered and stored Ivi the format necessary for the program. To ch«ck out 
the data, separate programs V7ould have to bo written to test each part of 
the Input data file f.-5r which testing was needed. Several sets of norrec- 
tiows to the data file would probably need to be made. 

The programmer (user) would then have to fill out some control cards giving 
various parameters of his data. Obtaining thewe .parameters roight involve 
so-ne manual calculations and may require run.iing some other programs 
on the original data. 

Finally, the tnathetaatical model could be run and, with several tteratlona 
and interpretations by the knowledgeable raathemairical progrftmming person, 
the problem could be solved. A report would have to be written explaining 
the problem and its compu-.er solution. To solve a similar problem would 
take almost the same steps, except that a lot of the existing programs could 
probably be vised, although ir.ajo'- revisions are also possible. 

Th.e existing data on a file tor solving this problem is most likely 
useable only for this application, even though parts of it may be useable 
for oth<;r applications. 

The time lag between problem recognition and problem solution will be 
too long and the cost will bs eKpenslve. It is possible that, without 
countless hours of detailed documentation, the program wfitLen U unuseable 
except tot one or a few pciople. 
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If v;e consider tha water pollution control planning oyntp.m, set ud an an 
application prograra with a file, the information on treatment plant coat 
data and the parameters of the rivers cannot be u«ed ea^iily by anyon:.' other 
than the developers of the system, unloss the '-.ew user knows die specific 
formaL of the data and hov it is stored on auxiliary memory. 

Motiv ation for the Developme nt of Ge neralised J^^^\, Planni ng Sys t egia 

We must define what a Genei-alUed T)a'Cc\ Management System iiiy before we 

define the characteristics of a Gentnali/.ed Data Base Plsun.ing Svaucrm, 

3 

Groner and Goel define and ch.-^racter L^e a Cenerall zed Data Management 
System as follows: 

"A GDMS consists of data, structure, and a set of algorithms for mani- 
pulating the data and the structure. It acts as a courmiunJ cat Lon channel 
betv^een the user community <ind the data base. Minker. characterizes 
GDMS as follows: *A daca management system is considered Rcner allied when 
it permits the manipulation of newly defined files and data with the existing 
programs and systems.* [a GDMS] facilitates reference to data by name 
and not by physical locatiouv' and, *[it] fricllltates the expreosloa of 
logical relations among data ltem:3.^ A v^rell designed GDMS permits usets 
to access and manipulate tilements of the data base in a way that Is both 
natural and convenient for them and efficient in terms of its syBteui 
utilization, 

^'Much of the benefit derived from a GDMS results from the insulation of 
the people and programs from the data* In conventicaai systems the structure 
of the data must be explicitly embodied i:i each propr^^m acccfcsing the dalta. 
Thl^ limits the application of programs to data v/bose structure has bceTi 
defined to them. It also limits the ability to restructure data in res- 
ponse to new needs withoul: modifying every program embodying the old struc- 
ture. These limitations ^n applicability of proRratns and the flexibility 
of the data base impose a rigidity upon conventional data prdC^BBlng syateftS. 
Vfliile this rigidity is not serious in repetitive well defined tasks such 
as payroll or Inventory control, it is a decided obstacle to the successful 
performance of systems that must respond to continually clianglng tequirements. 
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*'GDMS systems evolved .trom sequential formatted f.tie 5)vsi:em.^. This 

evolution has been in the direction of mort^ conipUix logical data strucCures 

3 ^ 

and more complex operations upon them/^ " 

The work on Generalized Data Management Systems untJl now has focused 
on two related, but distinctly different approaches' to the design of data 
mauagement systems,^ The first approach involved the deeign oC a speci/al 
query system for rcLrieving data from a data base. This approach penuitted 
new programmers to readily access data and to ask aophlstica^ied questions of 
the data base. The query capability made this approach very popular, but it 
has a serious drawback. Namely, that it is extremely difficult to process 
other applications written in FORTPJ\N, COBOL, PL/1, etc., againat thf? 
data base. Examples of the fixr^it approach are Inforrndticj? Mark IV and GIS 
of IBM. As a result of this deficiency, many people preferred thc=i second 
approach which Involved extensions to host languages (FORTRAN, COBOL, etc.) 
that gave the programraor some general file handliup. capability. However, 
the non-program!ning ustr found this approach undesirable, since, if he warted 
a quer>' answered, he nad no write the progr:im(s) in the. host language 
to retrieve the data. Examples of the second approach are General Elactrlc's 
IDS (Integrated Data Store) and Burrough^s Disk VORTb (Disk File Organization 
Technique) . 

Now the CODASYL Data Bai^e latik Group^ has proposed fsee Appendix A) a 
solution to the problem, but in Its specifications has given flrfM: priority 
to the host language approach, with COBOL as thf. firdf: language. To inter- 
face between a host programming language and a data base^ ^ specific sub- 
schema Data Description Language and an appropriate Data Manipulation 
Language need to be provided. Wien an interface :U pa^viried, applications 
still must be implemented in the J:ipecific host language syscem, (While thie 
may not be a problerri when and if the standardized implementation of CODASYL 
DBTG concepts occurs throughout the industry for the nn ]or higher level 
languages, it is quite a drawback for several years to come.) Even i£ 
CODASYL*s concepts wer^? '^il implemented^^ we are still v7ithout a system 
that a planner or manager could easily use. GPLAN is propoaed as auch a 
system. 
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GPL^\N is s f^yntlieslf? of compoaenUu from other uystpftis^ 'There are a 
number oT systems tha^: exhibit some, but not all^ :)f rho features of 
GPI-AN, Examples of so\x\e of thcifie. systems are: 

•J 

1, NAPSS: Numerlca.l AnaLyf?ls Pi^ohJem Solving Systevn/ 

0 

2, SODA: Systems Optlvnlxation and Design Algori th,Tn, *^ 

i S 

3, GDMS: Generalised Data Management Systcris, ' 

(a) System 2000 - MRT^ 

(b) RAMTS - Mathematical Inc.^'^ 

(c) IMS - IBM'^^' 

(d) DISK FORTE - Burroughs Corporatlo.n^^ 

OPTIMA, 

Mu merical A nal ysis Pr obloin S^olviug ^ Sy sjL e m ^ (N AP S S)^ 

A system that is a speoiaJ case of GPlA^ is the Nunetlcnl Analysis 
Problem Solving Sy.stcm (MAPS:') designed iind imp-ementod at Purdue University. 

A long recognized goal of Coriputer Science, hns been to facilitate the 
stating oC problems in ,Ianguages appropriate to the r,pecif?c fields in which 
the problems exi^st, di\v, ciiien to provide for this solution without the 
services of highly trained prograra^ners and aralysi:M. Thejre syotems are 
''problem solving sy^- t.?mr.^' and thp.ic languages are problen.**orlentod languages. 
Thus the aim of the NAPS'; project is to make uhe oomouter behave, as if It 
had some of the V.nowl::jdge , ability, and insight of a professional numerical 
analyst. 

A user unskilled in nwriarieal analye^ls cnn depcrib^^ relati\re.ly complex 
problems In a simple mathematical language. Then the syacem nelects algo- 
rithms, perfornff analyses, and gives diagnostics of possible difficulties 
and meaningless results. 

The problem-'oriented language of NAPSS use? 8o.n'* of the applicable 
notation of Fortran, Algol, and PL-1, eslnce th-ay have quU:e sirnllar facilttl^^s 
for describing computational algorithmb. But it gcey beyond thesa languages 
to include mathematical concepts such an Integration, dlf f erentlatlont 
algebraic and differential equcition^i , and approximation an part of the 
basic language* 

Tlie basic approach to the system design is through the developm^ftt of 
polyalgorithnis which become the numerical analyeia packages that are th^ 
essenclal elements of the problam solving systeti), polyalgorithtrt is 
formed by the synthesis of a group of nuitiefical tnethoda and b, logicial 
structure into an integrated procCidure for solving a &ipecific type of mathe* 
matical problem/*-^ The goal of a po.lyalgorlthtn is to combine 
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a number of algorithms (corresponding t:o numerical vnetho'is) with n 
strategy Cor their selection, >xn<l use a procedure whlcb is relatively 
efficient aud very reliable* 

The NAVSS system exists as an extension of a procedure-oriented 
language in an qnvironnient:^ permitting both on-line and remote use of 
the system. Initially, NAPSS statenients were treated as macro- S;tatements 
in Fortran and were expanded in-line into a sequence of Fortran eUitc- 
ments which were input to an incremental Fortran processor. While 
NAPSS operates most frequently in an online time-sharing environment, 
it will accept programs submitted for batch proce^ising. Parameter 
values that are needed by N.^3?SS can be entered at a terminal in convex-- 
satlonal mode or be present on a standard or user-named input file 
for either conversational or remote mode. 

In figures la and lb we can see how NAPSS can be put into a more 
general structure with a renaming of its components. 



Standard or 
Named Data File 



Tvicrementnl 
ProblGin--Orlented 
Language Analyzer 
(Expanding Macros 
to Extend Procedure 
Oriented Language) 



Problem-Oriented 
Language 




Poly algorithms 

(Sophisticated 
Groups of 
Numerical 
Methods) 



Figure la: NAPSS : NiAnerical Analysis Problem Solving System 
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Figure lb: NAPSS - GPLM Terminology 



SODA ( S)^ steins Optindzei tion an d Design Algorithin) 

SODA Is a coinputer"-asMisted decision mak.lag system for the design 
of information proce^ising systenifi^ SODA generates a complete Infonaation 
systems design, ^ilong with coHt/performance projections' of how the designed 
system will perform on a 3pecif:i»?.d hardware/sof tv/are conf iguratiotu SODA 
consists of four major conponenti?: 

SSL: SODA STATEMENT LANGUAGE 
SSA:SODA STATEMENT ANALYZER 
SGArSODA GENERATOR OF ALTERNATIVES 
SPLtSODA PERFORMANCE EVALUATOR 

SSA is a computer program that analy^e^ the requiremc^nts of an infoftnatloft 
processing system fstated Jn SSL, Tht^ Statement Analyt&er al^o provides feed* 
back information to the usv^.r ic assist him in achieving a better problem 
statement. 

SSA also produces a Mimber of networks which record the interrelationships 
of processes and data and pasjues the networks on to SCA and SPE* 

Each type of input and output is specified in terms of the data Invelved^ 
the transformation needed to produce output from Input and stored data* 
Time and volume requirements are also stated* SSA analygea the itatamefit s£ 
the problem to determine whether the required output can be predueed from 
the available inputs i The problem statement stored In waehlne read^ibla tQm 
la precassed by SSA whlehs 
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1. checks for consistency in the Problem Statement (PS) and checka 
syntax In accordance with SSL; i.e., verifies that the PS satisfies 
SSL rules and is consistent, unambiguous, and complete. 

2. prepares summary analyses and error comments to aid the problem 
definer in correcting, modifying and extending his PS. 

3. prepares data to pass the PS onto SGA, and 

4. prepares a number of matrices that express the interralationohip 
of Processes and Data Sets. 

SGA is a procedure for the selection of a Computer System(cpu, corg 
size, auxiliary memory devices) and the specification of alternative 
1 designs of program structure and file structure. SGA constructs a conflRu- 
ration of equipment in order to evaluate performance of the system. A 
number of models are used (to compute timing estimates) that select timing 
factors for alternative hardware/software configurations from a data file, 
SGA simulates the jobstream as it would be processed on the selected 
configuration, and^ using the factors from the hardware/software library;, 
SGA and SPE produce detailed cost/perforniance projection reports so 
that the user can evaluate the final design. 

There are a number of systems similar to some aspects of SODA, such 
as SCERT^^*-'-^ and CASE.''-^ 

In Figures 2a and 2b it is shouti how SODA fits into a more general 
structure . 
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Figure 2a: SODA: Systems Optimization and Design Algorithm 
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Figure 2b: SODA: OPLAN Terminology 
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Ge neralized D ata Maaagement: S yste ms 
SYSTEM 2000 

SYSTEM 2000, developed by MRI Systems Corporation, is a general-purpose 
data base management system* The basic system provides a conprehensivo set of 
data base management capabilities, including the ability to define new data 
bases, modify the definition of existing data bases, and retrieve and update 
values in these data bases. 

In SYSTEM 2000, the basic components of data base definitions are 
data elements and repeating groups. Values are stored in data elements- 
Repeating groups describe a structure for storing multiple sets of data 
values (data sets) and also «erve to link hierarchical levels of the 
definition. 

Values for each eleme- t and logical entry (record) may vary in length. 
The user may specify without restriction which elements In the data base 
are to be inverted and become key !^lelds, and what hierarchical relationship 
an element will Vave with other elements in the data base* Data security 
is maintained by password control to the data base and additional password 
control to each component. 

The Procedural Language fe.ature of SYSTEM 2000 enables users to mani- 
pulate data in a SYSTEM 2000 data base from COBOL or FORTRAN. This feature 
provides the mechanism to address any part of' the data base of interest to 
the procedural program, to retrieve data in a sequence and format suitable 
for procedural processing, and to update the data base from the program. 
RAMIS; Random Access Manag emen t In formation System 

RAMIS, developed by Mathematica, Inc, , is a data base management 
system which permits a user to describe and build data bases, maintain the 
data in the data bases through updates, additions, and deletions, retrieve 
information from thf) data bases and display it in meaningful report fortmts^ 
or pass the Information to other processing prpgrams.^ 

RAMIS is both a report generator and a data manageme^nt system, since it 
has a simple and logical English-like language, which petffilts the user t© befeh 
request information from data bases, and, at the same time, process it ititQ 
finished reports. 
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RAMIS organizofi t:he physical placemenu of data into iree structures on 
random access devices by exploiting the hierarchical relationships of the 
data fields. The user has to supply only some minimal information about these 
relationships. User written programs in Fortran, Cobol, Assembler, or 
PL/1 c<in also be linked directly into RAMIS. 

IMS: In formation Hanagem ent System 

The Information Management System (IMS) is a system designed to facili-- 
tate the implementation of medium to large common data bases in a multi*- 
application environment.^ This environment is created to accomodate both 
online message 'processing and conventional batch processing, either 
separately or concurrently, llie system permits the evolutionary expansion 
of data processing applications from a batch-only to a teleprocessing 
environment. 

The data base processing capabilities of IMS are provided by a facility 
called Data Language/I. The data base functiors supported are definition, 
creation, access, and maintenance. The ful] data base capabilities of Data 
Language/I can be used in the IMS batch processing or teleprocessing 
environment* 

Data communJ cation capabilities are characterized by the use of 
input/output terminals in remote and local environments, connected to the 
computer, which provide the user with access to the data base, IRS also 
has extensive message scheduling, checkpoint, and restart facilities. 

DISK FORTE 

Disk FORTE, the Burroughs manufacturer system, is programmer-nriented 
at the most basic level. Nearly all features and capabilities of other data 
management systems must be programmed in Disk FORTE. Yet, it permits both 
hierarchic and netv;ork data structures (user^programmed, of course), which 
make possible more complex asiVJciations among data* 

Disk FORTE makes its data management capabilitiCis dvailabU through 
extensions to COBOL which are. handled by a pre-compiler . 
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Figure 3 shows the generalized st:ruct.ure of SYSTEM 2000, R^\MIS 
IMS and DISK FORTE, 



Data Basc^ 



Interface 



Data 
Man ag omen t 
System 



Query Analyser 



Que:!^y Language 




Figure. 3: Gene trail Data Managemi^nt Sydtetn 



OPT IMA 

OPTIMA is an advanced mathematical prograiiuning syFitem for the CDC 
6000 series computers. It includes advanct?d algorlthraB and techniques In 
addition to algorithm^i for standard linear prograiiuping formulations* User- 
controlled data and storage management features are also provided • 

"The basis of OPTIMA Is a revised product-form, composite, bounded vari- 
able, separable, multipricing > simplex, linear programming algorithm/* Some 
of the advanced features that OPTIMA provides are: the capability to form 
a nontrivial starting basis; the ability to start a solution using a 
previous basis; dynamic control of the frequency of inversion of the 
basis matrix; provision for partial and multiple pricing; the use of maps to 
exclude or include specified vectors in the basis; and elaborate recovery 
procedures. A dual optimization algorithm is available for those problemB in 
which its use might be advantageous* and postoptlmal analysis of a problem 
can be accomplished at^ an integral part of OPTIMA. 

Through the use of the Applicr^tions Control Language (ACL), OPTIMi\ 
allows dynamic control of the progress and execution of the program. ACL 
has logic and computational capability and provides verbs and phrases for 
modifying variotis parameters and controlling the progress of the solution. 

An ACL program must be written for any study. This program defines 
the data files to be used and the operations to be performed on these 
files, sets any parameters and controls necessary, and calls varloua routines 
required to carry out the study. 

Two other languages > th^j Matrix Generator Languaf^e (KGL) and the 
Report Generator Language (RGL) operate within control of the ACL, MGL 
provides capabilities for generating a problem matrix automatically, 
RGL provides the capability for generating reports in any deriired format^ 
and permits computer-generated solutions to be used for further aritJimetlc 
and logical computation. 
Sumcmary of Comparisons 

Figure shows the structures of GPLAN, In conaidfttflng the four 
information processing systems 1) NAPS 2) SODA^^B) GDMS^and 4) OPTIMA^ 
it is observed that we must have at least a query language ^ a query andly^et 
and a Generalised Data Management System. NAPSS and SODA ate ffllssing the 
data management capabllltieB; the GDMS*s are missing thoae components neisded 
to readily Interface models r^^'^TIMA is missing the data mAnag^Jimeflt and query 
cApablllties. These differences affe elal^jfited on in Table I, 
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Figure 4: GPLAN: Generalized Data Base Planning System 



ERIC 



21 



Miu'OiOnlc vail 
of 



eys'em? 



DISK 



■mwmmm 



la-. ' '0 aiming 



r./Hte(iiy 
fnt tun 



?v y^ji cm 

So IV 



Tnfnrtsust ton 



IMM Pur iue U. J Pur/iuf 
™^ aLiiLMjl^Ui 



p TfiC lOli 



B2500, ci^cfii'OO iBM/»'3C, i:n:vac .intiCDroSOO 



':iJC6coo 



VJCi/ V.0.370 



Miinuf ac- 
turer */i 

dbm:; 



top. S7.5' M' 



f .trer 'a Dfty.S 



^'OUTRAN UAL 

w 



KOKTKAN 



User U*)n{^uage 

TiT 



(ScJiAgc Siruc- 
ruiea - undo I* 
u«cr control 
if vl.nbiu to 



ox! fdo ionn 

hulcx-Ran- 
doiu^ Jrilt-x- 
Sc^jucnt lal 
(vislbjo to 



Seine 
'.urc 



coijo:., 

K HAL 



Sequential 
D Irec I 

fvl4i<bU' to 



CidJ 



FORTRAN 



ML 



Oati* 81 rwc tutus 


Hi ^rarchic 
or Ncti-'.^rk 


lllpr;if Mut 


HLT^-rhlc 








Trofi 


hlrr.ircUU, 




St 0 vagi' Medio 


Head -per- D'. rci* • 
t . nak -Dli'i.*t;t' Aci c^;»a 
Access Di-vlCL-fi nevl^e** 


Ml P I 
'Vjc e:.9 


At r v'tffi 
I'c vU te 






Mrtscc 
Ar cess 
Ov^vicey 


Ac 'on-: 













>: l^^ 






Jl 


















X 









User LatifituABv 
C'astlflcnctiirs:- 



Procedural 











msms 


^ 


mmsm 








Daca BiJse Queries Allowed? 


:< 




X 


I 








Jw. 




AppiicAClun '-^aci ijpjes or ModelB 
(|iiftr luo A] ' 




X 


r 


y. 











fX4l'i»:/iii'.i*^!.^.L^.^. ^•.^"S'^iU? 








...... 






, • 






Query Annlyjtcv: 
N^^^;.*??.f'i "-'IS.f.^^rl^?. 
















'K 


1 




Application ?;u kjgi- Vodiji 

. . .iy^^J.*^!. - —J 




X . . 




X ^. 












\ 




Y 


X 


f-.-<^.i V... 




^'^.pii^^/itl.c. A.4ri:>ji,l^^ ^ 
















M<Jtltr»nv*u lea* -tn-^. op*-'r»i- 
ziiiion models . , 








y 


X 


.^,„, 


1 
1 








X 










^ 




^^/'Mi/\L!"-\!\ 








■.; 










Any l'fo?.rom 

. ( 
















\ 




Any J^al:kflge (gronp of 

JnLerconneL-tiHi,^proKr^^«}s).., 




















Cosnp-irlson wltij Gl>bl*S 
Cofflpon?nts : 

^ U^r , 




X 


...J... 


X 






;< 


J' „^ 




. .9^^7>v>^,^B"*^a^' 




/ 






x.., 




V 

.... 










s 






...I 




X 


.A,.,. 








„ A.. .... 


ii^^- 














. . ~.-.Jl>mi^F^.,..,.. 


V 


..^ . 


J 




- 










^ ^r\jJ}^:'^ ,.. 




,. L... .. 


Jf - J 






.J 













y 

...» 















tou1« 1 



t) %<• a >t 1^ rt 4 1^ o» O-tta »*«tt*«f 



19 



Compo nents of a O eneraUzed^JataJ^ 

A synthesis of the previous systems results in the definition of 
the following nine components of a Generalized Dara liase Planning 
System: 

1. A Generalized Data Management System (GDMS) 
2 ■ Raw Data tor the Data Base 

3. A Query Language 

4. A Query Arialyzer 

5. A Collection of Application Packages or Modela 

6. Administrative Report Module 

7. User's Interface 

8. Extraction Files 

9. .Users 

Each of these components is diracussed in more detail in the following 
sections. An overview of GPLAN for W.iter roUutlon Controii Is fihown 
in Figure 5 and Figure 6. 
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A Generalisied Data Base Maivigemcnt System that is implemented at a 
particular installation under a specified operating system must be 
available. The GDMS must meet minimum requirements as to data structure 
definition, data base loading, data base updating, and data base retrieval, 
and it must satisfy some minimum set of queries, as specified in the 
following section. 

Six general functions must be provided by the GDMS: 
Input - the System accepts data values or information about data structures. 

Search - the system searches the data base by examining the descriptions of 
data structures and storage btructures to ascertain the existence 
and location ol: certain data values. 

Storage - the system accesses a data base to add, insert, modify, or delete 
data values. 

Maintenance - the system generates or modifies descriptions of data, data 
structures, and storage structures to adapt to change. 

Retrieval - the system accesses a data base to obtain data values previously 
stored. 

Output - the system exhibits data values or information about data structures 
and storage structures. 

2. Raw Data f.or a_Dat.a Base 

The raw data for the planning system must be available in whatever 
form it can be collected* A Data Input Module is used to convert the raw 
data into a form necessary .to be loaded by the GDMS into the data base. 

To refer to the data in the data base, the following terms, adapted 

from the CODASYL Data Base Task Group Report, are d^^fined: 

DDL - Data Description Language. A language for defining data and their 
relationships. The DDL is divided into schema and aub-achema. 

Schema - That part of the DDL which defines the ''universal" data base. 

Sub'-schema - That part of the DD^ which describes the data known to each 
application progran or model. 

A schema describing the data on the data baar^ must be prepared. (Note that 
the DDL is not necessarily the one defined in the DBTG report.) 

Wliile preliminary Data Input Modules would be dependent on the fotffflat 
Of the raw data and dependent on the GDMS, it is hoped that idffle measure of 
Independence can be achieved in the same manner as the data transfoiffnatloni 
used in implementing the user interface mentioned later. 
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A Basic Query Language (BQL) defines all those queries that can be handled 
by the GDMS alone and allows the user to requejHt tl\at the DBMS dlaplay certain 
data or answer questions about thci data. The BQL Is a compararlve and computation- 
ally oriented language used to compare It.eni values with other Item valuen, or 
with constants, or with results of computations. Arithmetic operatorsi define 
the computations to be performed, and logical operators combinu simple expres- 
sions Into t:oinpound expressions. 'Vho BQL can be extended as application packagei^ arB 
added r:o include questions that are answered by the new application packages, 
i.e., each package adds a sec of new query components to the BQL* The BQL, 
together with all the query components from the applIcatioa.'i packages, makes 
up the Query Language (OL) , 

General capabilities provided by the QL are: 

Selective rGtrieval - tho user specifies the selection conditions to be 
satisfied in retrieving the desired data. 

K on s e 1 ec 1 1 ye r e t r U v -a 1 - the user specifies unconditional retrieval of 
^ daca. 

Conditional re t r i e 7g 1 - t.b?. user timploya verbs such as TF«.#».ELSE to test 
itfims for some qualifying values In deternining alternarlve courses of 
acl'io;^• 

a tat is t i g air e trie yal - the user may query the system about data. Statistical 
computations for all the lustancea of one Item , for example, wculd include 
maxiiuum value, minimum value, mean value, median value ^ mode value, standard 
deviation, aud total number of instances* 

The QL thus should provide the capability for easily asking questions of the 
data hfise and asking questions that can be nandled by the various application 
packages. By including optimization models In the application packages, the 
policymaker Is able to move etflciently beyond the *'What if.'' to the **What's beet'' 
question. Moreover, much additional ^;c^search needs to be done on the query lan- 
guage (and its associated analyser)., evince Its enhanc^.ment adds much to GPLAN# 

As an example of the power heeded in the quety language, cone ider the add^d 
components of the planning model from the ReRicnal Water Pollution Contrbl Planning 
System. It is able to handle two distinct types of planning problems* First, It 
is able to select a least-co.Mt combination of treattaent methods^ given water 
quality goals and economical ♦ political, and water quality inforttiatlnn from the 
river basin. The second typa of question which can be handled la directed fewarda 
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individual projects. Types of individual planning problems that could be 
analyzed are: 

a. What is the least cost solution for towns X and V to handle their 
efflueut? Should they combine to construct and operate a joint 
treatment plant? 

b. Wliat would be the least cost solution if consideration is given to 
the political constraints that may become operative? 

c. What is the optd-nal plan for capacity expansion giving consideration 
to the growth and nhift of population and Industrial growth in the 
basin? 

d. What are the least coat and optimal treatment plans that correspond 
to the task of providing water of high enough quality for certain 
recreation activ:'ties? 

e. Wliat is the sensitivity of the optimal pollution control plan to 
costs and constraints? 

r. What is the optimal tradoff between water quality, flow and alter- 
native costs? For example, what v/ould the difference in costs be 
if a plan was to permit the violation of a vMter quality standard 
once in 25 yeara as compared to once in 50 years? 

GPLAN is a methodolcgy for obtaining answers and responses to the above 
type of questions. 

4« A Que r y Analyzer (QA) 

A Query Language Analyzer must be able to analyze the BQL and as many 
application package query components as are available. A user enters his 
query in the Ql^ and the Query Analyser analyzes the question and provides 
the user diagnostics to help him reformulate his questioi'^ if necessary. 
The query stored in taachina readable form is processed by the QA which: 

1. Checks for consistency in the Query and checks syntax in 
accordance with the Query Language; i.e., verifies the QL 
rules and is confilstent, unambiguous, and complete. 

2. Prepares error comments to aid the user in correcting, ffiodifying 
and extending his Query. 

3. Decides whether to pass the Query to the GDMS or one of the 
application packages. 

4. May request additional information from the uier if the action to 
be initiated requires it. 
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5^. A Collec tion of Application Packages or Models 

Application packages are sLmulailoa and optimization models, statistical 
packages I and other self-contained systems currently functioning under a speci- 
fic computer and operating sys^tem. 

We want to make it as easy a^s possible to add application packages, ao we 
generalize the process by describing how we add a specific package* 

We will make several assiiinptions about appJlcatlon packages: First, they 
are already running as batch jobs rather than Interactive jobs. They may have 
quite long running times and making then interactive may simply mean waiting 
at the terminal; Second, they require user preparation to get the data ready; 
and third, they require other programs to run before the input data ici 
complete . 

We must know certain cha^* cteiistics of an application package or model 
before we can consider tyin^ it into GPIAN: 

A. Input 

!• For each data input, we must know what kind it is (pure data 
or cotmnands) inxd the cis^octated types and formate. 

2, For each data input, we must know what kind of device it is 
assigned to (sequential or random-accesn) • 

3, We muyt knovr the pcxs^seh and correct logic steps and transformations 
to go from the data t>A*se to each input. 

4, For each data input, what must be included in system queries to the 
GDMS for 3 above? 

B. Output 

1. Is the output self-explanatory or does it r^:quire minor explanation 
in the form of good documentation In the Query Lanjjuage description? 

2, Does the output require' much technical knowhow to interpret the 
results? If yes, an output interpretation module is required 
(e.g. nonlinear river basin model solution.) 

C. Wliat query components can it add to the Basic Query Language? 

D. ^^inimal Documentation to.be used by: 

1. Systems personnel 

2. Non*-programmer researcher 
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j6, Admlntstratlvts Repo n Module 

The /ulministrative Report Module v;ill produce standard reports that 
must be completed and filed on a routine basis. These reports may be 
automatically triggered by queries or specifically requested from the 
console. 

The standard reports will be supplied with data from the extraction 
file structure. 

7. User's In terfac e 

Each interface component required for each part of an applications 
package must be defined: 

A. Simple input linkagti direct to the Data Base. 

B. Phased inputs — including self- started and analyzed Data Base 
retrievals . 

C. Any combination of A. and B. 

D. Simple output — direct from package. 

E. Output interpretation module iieeded. 

8. E:i;tractlon Flies 

Between the data base and the set of application packages and the 
Administrative Report Module ic a set of extraction files containing those 
items from the data base that are uyed for the packages and reports • 
Questions to be answered ou extraction files aret 

A. How many should there be? 

B. What items should they contain? 

C. Wliat should their data structure and storage structure be? 

D. Hov; often should they be updated? 

E. If a new application package or report is add^^.d, what changes 
should be made in the extraction file structure? 

F. Should some application pa/'agea bypaas extraction files entirely? 

9. Users 

There are t /o types of us^^rj connected with GPLANj the technical 
systems petf»cnnel and the nontechnical administrator ot Mtiager. 

A data admltiistrator and his systems ^itaff are responsible fort 
all original data input updating of data? resttuctulflfig thi fiata Bass and 
extraction fil^s as necessary; changing machines and operating systems} 
adding new pac'.'.ages, standard feports (Adffiinlstfatlve Report Module), 
and other additlonv^ or improvements. These eysteffls tisers^ taksfl as a group* 
must understand fairly well ev<>ry component of GPLANi '^hey possibly 
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could get by with not being familiar with some of th« application packages, 
but then vould have to get consultation to patch up or improve on these. 

The major group of users are non-programming adminiacratora . These 
are users who don't know how to program, probahly don't want to learn, and 
definitely shouldn't have to learn. They have a jj;ood understanding of the 
area for which the planning system was designed, of will have to have some 
training in this area before using GPLAN. Most of the details of the 
GPLAN implementaticn should be transparent to thp.se users, and they should no 
notice any changes in the system, except the addition of new capabilities 
(possibly requested by them), new efficiency, or new packagct The success 
or failure of GPIAN depends on how well these users are able to carry out 
their querying of the data base and Interaction with the application 
packages using only the quety language and its documentation. 

RFMS and RAMIS t'.djtiy maet and/or exceed the minimal requirements 

for H GDMS as specified above. Thus 
all- software bein^ developed for GPLAN is being Implemented on the CDC 
6500 and the. IBM 370/i5.'3, 

Research is proceeding on the Query Language - Query Analyzer 
components in threo areas. One axerj of investigation io the relationship 
between the QL and QA and the SODA Statement Language and SODA Statement 
Analyjser as used in the SODA project. Second, research on QL and QA is 
proceeding as a result of the development of the water pollution control 
models, FinaJly, the state of the art in artificial intelligence is 
being investigated for incorporation into the query langviage and analyzer. 

Status of GPIAN 

There are two major efforts under way with respect to the development 
of GPUN: 

1. Development and construction of the software for GPL\N. 

2. Work on a teal world planning system (Water. Pollution Control) 
and development of une.c training aids. 

1. Development of Software f or_ GPLAN 

Two different GDMF systems are being evaluated in paraUel with thi 
eonatruction of GPLAN. Development is ptoceediftg using RAMIS and RFMS 
(Kemota Fil^-. Management Siystein). RFMS is a version of* SYSTEM 2000 that 
was originally developed at the University of Texas at Austiii. RFMS 
has been converted to run under the Purdue M>\CE Operating Syetetn^and 
subs<:afttlal improvements have be«n added to the original versioft. 
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The two moHt cliffJ.cult ari^.as in the development of software for 
GPLiVN aru the User's l.utt-.r faci-^ and the ExL:rac.tion Files. Thu3, a Data 
Description Language schema for data base description^ and the Data 
Description Language subschema for the description of application package and 
administrative report data requirements, have been defined. Research la 
proceeding on the autonu^tic m^ipping between the data baor achetna and an 
application package's oubscheina , Included in this mapping is a set of 
extraction files to be composed of subsets of items from the data base, 
An integer programming model has bcr.i defined which relates the data 
items of the data base to those on the extraction files as required by the 
appHcHtion programs. Also, a cofU: fv.nction representing the cost of 
operating GPUN has been defined. An important a^ipect of the problem is 
the optimization of the extraction files by Holvlns for the extraction 
file arranjjement which minimizes operating costs, 

2* Wqrjc on a Real Applicat ion 

Data is presently available to us from a previous s^tudy on the West 
Fork of the Wliite River in Indiana for the d^jvelopment of a demonstration 
project concerning the Water Pollution Data 3ase Planning System. The 
insight achieved through i:he dovelopment of a specific planning system 
has already proved to be tromendous old in che accomplishment of th« 
major goal of having a truly easy-to-use system. 

The query f,yste.ra is being Implemented in two modes: 

1. Standard 80 column teletype 

2, Graphics Terminal 

The usefulness of GPLAN is enhanced ^considerably through the effective 
use of a graphical di^iplay. The graphics terninal offers the obviops 
advantage of being able to output designs, graphs, etc., in a more vlsable 
and appealing form, hvt the main arivantagt? of interactive graphics la that 
it offers the user the capabllltv of complete user interaction with the 
planning system. 

Consider, for example, the river basin planning system. The optlffll2delen 
models output a diagram of the optimal solution to a <jpeciflc water pollutioti 
controiP'^^^^^^'""'' showing the actual location of treatment plants and cooling 
towers on a computerized representation of the river bASin, i«eM the acfeual 
solution is lllusf rated on a map of the river basin. The use? My not have 
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much confidence in th« results, but he can at least relate to the output in 

this form. However, If he is given uhe opportunity to improve the solution 

by making adjustments to the design^ or by changing the location or capacity of 

a treatment plant through the graphical query system^he finds that he i3 • 

part of the decision making or planning process. Now, we can let the user 

input his own design and then compare the value of the ,o^ ^ective .function 

for his design with the optimal design. GPLAN can then Indicate whether or 

not his design is even feasible. The user can also be given the opportunity 

to experiment with the values of thf constraints and try different water 

quality goals. The result of this interaction is that the user has increased 

confidence in the planning system with a unique appreciation of the special 

talents and capabilities of man and machine. 

The user can only be convinced that the mathematical solution is 

''good" if he can't Improve on it himself. This experience was also 

supportv?.d by observatiors from a project concerned with the location of a 

17 

major highway in southern California. 

Interactive graphics allows the user to utilize insight that 
often can't be built into models. This man-machine interaction enhances 
the planning system and brings the uv^er into the decision making process. 
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Appendix A The Data Base Task Group Proposal 



from: "The Debate on Data Base Management/' EDP Analyzeri 
Vol. 10, Mo. 3 (March, 1972), pp. 4--5. 

What was proposed 

• In designing the specifications for two data description languages and 

a data manipulation language, the DBTC was faced with many options. They 
could choose to embed these languages in one or more ''hcst'^ programming 
languages, or they could choose to make them self-contained. They could 
orient these languages toward the application prograiiuner, or toward the 
non-programming user; that is, they could be procedural or non -procedural . 
Or they could choose to support both the application programmers and the 
non-progranuning users. 

The DBTC selected what they considered the highest priority tasks to work 
on* They chose the host language approach, wiuh Cobol being one host language • 
And they chose to specify a DML at the same level of procedurality ;is Cohol. 
At the same time, they designed the DDL and DML so that the general data 
base could be interfaced with otheijprogramming languages • They deferred 
work on non-procedural languages cis being less urgent than the procedural 
languages — but they rccogr;ir.od the need for the non -procedural languages. 

We will briefly coven* some of the key tenis involved* The name schema 
DDL was given to the source language for defining the complete data banc. 
It was to be totally independent of any one progr?vr:.ming language but able 
to interface with a variety of them througli Aryropriate sub-schema DDI/i. 
The term sub-schema DDL appJicd to those DDL oT^es that describe the part 
of the data base known to one or more sptcii'lc rrvgrajns, written in one 
programming language, A translation may be r.o^;'''*.* between the way data is 
stored in the data base and th:^ form in *.^h'ch il is *\eeded by an application 
program. This translation voiiid be defined by the matca between the schema 
DDL and the sub-schema DDL. An area is logical cor^tainer which can hold 
records and which can be mapped onto st^rfKjjc in. 'la, h set of records is a 
group of related records, associated by rcinters or pointer arrays. Each 
set type has one record type declared as the owr r> and one or more types 
declared as members • A data base-key is a unique rsavrd identifier, 
defined by the implementor, from which rho 't.rea and location within the 
area can be determined, ITie implementor may cho^so to- uake the physical 
record address directly derivable from the database-k^y. 

Note that a sub-schema DDL and an appropri^^-te DML provide the interface 
between a host progrcimming language and the data base. Note, too, that the 
DBTG proposed specifications for the Cobol sub-schema DDL and the Cobol DML. 

Cobol sub-schema DDL. Four main sections of the Cobol DDL include the 
Renaming Section, Area Section, Set wSectidn, and Record Section . The 
Renaming Section allows the data administrator and application prdgratnmer 
to I'elate names in the Cobol sub-schema to the names in the complete data 
base schema, to provide conformity with what the host language fequires, 
(For example, Cobol can have 30-Gharacter names, while Fortran can have 6- 
character names)* The Area Section allows enumerating the ateas of the 
schema which are included in the sub-schema--and by implication^ to refflove 
from view all other areas of the schema. It is convenient, but not stfietly 
accurate, to think of areas in terms of storage media- -tracks or cylindefS 
^ of mass storage, magnetic tapes, etc. So in the Afea Section, those poniOftS«# 
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mass storage which the program(s) can access are named. 7'he Set Section 
allows enuraerating and defining the seta of the scliema that are to be 
included in the sub-scJioma and again, removing from view all other 3e-:s, 
Finally, the Record Section allows the ncuiiiiig and definition of rcccrd types 
within a data base* 

While somewliat similar to the record descriptions in Cobol, the Record 
Section does differ from it in important respects. The Location Mode, 
copied from the schema, defines the means of accessing thi record- -by 
calculation (randomirJng) , direct (by database key), or by searching 
through a named set. The area to which a r'ecord is assigned is named. 
A record privacy lock can be included, for various types of access. Each 
data field is defined by Picture, Usage. Sign, Occurs, and Privacy Lock. 

Cobol DML. Fifteen verbs are defined, for storing, retrieving, etc.; most 
of these have two or more optional formats, as in the case of the Cobo.T 
verbs. The verbs and the number of optional fonnats for each are: Open (2) 
Close (2), Insert (2), Remove (2), Moaify(2), Order (2), Delete (1), Find(7), 
Get C2), Store (1), Free (11, Keep (1), Move (2), If(2), and Use (i). 
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